This invention relates to a method and an apparatus for securing the programming data of a programmable device—e.g., a field-programmable gate array (FPGA) or other programmable logic device (PLD)—against copying, and to a programmable device so secured.
Programmable devices are well known. In one class of known PLDs, each device has a large number of logic gates, and a user programs the device to assume a particular configuration of those logic gates, frequently using a software tool provided by the manufacturer of the device, with the software tool being executed on a computer having an adapter into which the device is inserted. Early generations of such devices typically used some form of programmable read-only memory (“PROM”) technology to store the configuration data produced by the software tool. In those early devices, the software tool caused the computer to “burn” the pattern into the PROM storage by fusing fusible links. In later generations, the PROM technology may have been erasable programmable read-only memory (“EPROM”) technology, which was not burned, and could be erased (for reprogramming) by exposure to ultraviolet light. Still later generations may have used electrically erasable programmable read-only memory (“EEPROM” or “E2PROM”) technology.
All of those technologies were relatively secure. In the case of a user who chose to use a programmable logic device rather than incur the effort and expense of a developing a custom chip, if a competitor of that user were to try to reverse engineer the programmed programmable logic device, the competitor would essentially have to slice the device layer by layer to discern its programming. While such an effort might be technically feasible, for the types of users being discussed, who by definition are not chip manufacturers, the likelihood that a competitor could or would undertake the effort was small.
Later, programmable logic devices that store their configuration data in static random access memory (“SRAM”) storage became available and remain prevalent. Such devices have the advantage of being smaller and faster than the devices based on EPROM technology.
However, SRAM storage is volatile; it does not retain its contents when power is lost. Therefore, programmable logic devices based on SRAM technology are used with nonvolatile storage, to retain the configuration programming data during times that the device is switched off or otherwise not provided with power. Such nonvolatile storage may be provided, for example, in the form of Flash memory, although any form of nonvolatile storage may be used, and it may be either on, or separate from, the device.
Whatever type of nonvolatile storage is used, an SRAM programmable logic device having nonvolatile storage of its configuration data is less secure against reverse engineering by a competitor of its user. That is because a competitor can monitor the data flowing out of the nonvolatile storage on power-up, and thereby determine the programming configuration of the programmable logic device. Indeed, the competitor need not even analyze the data stream, but need only record it and store it in its own devices.
Commonly-assigned U.S. Pat. Nos. 5,768,372 and 5,915,017, each of which is hereby incorporated by reference herein in its respective entirety, describe the encryption of the configuration data stored in the nonvolatile storage and its decryption upon loading into the programmable device, including provision of an indicator to signal to the decryption circuit which of several possible encryption/decryption schemes was used to encrypt the configuration data and therefore should be used to decrypt the configuration data.
Subsequently, the programmable device market has become more sophisticated. Previously a device manufacturer would sell blank programmable devices to an original customer who typically would program them and sell each device as part of an end-user product. Thus, the manufacturer's original customer typically was the only party providing configuration data and therefore the only party needing to protect configuration data. More recently, vendor-provided proprietary configuration data for various commonly-used functions (frequently referred to as “intellectual property cores”) have been sold either by device manufacturers or third parties, freeing the original customer from having to program those functions on its own. If a party provides such proprietary configuration data, it may want to protect those data from being read, but the original customer needs to be free to add additional proprietary configuration data from another vendor (which also will want to protect its proprietary configuration data), as well as its own configuration data, and then to protect the final configuration including its own configuration data and any vendor-provided configuration data.